Merciful 4/Merciful - Disc 4.iso/software/p/psychotoads.dms/psychotoads.adf/a1113

Text File | 1989-03-31 | 60KB | 1,565 lines

                         11: HARDWARE SPRITES                              145
                      --------------------------
One of the biggest attractions of the Commodore Amiga is its ability to
produce high quality games which rivial those found on genuine arcade
machines. This can be amply demonstrated by terrific programs such as
Battle Squadron and Eliminator.

  Now, for the first time, all these amazing features are at your
fingertips! AMOS Basic provides you with complete control over the
Amiga's hardware and software sprites. These sprites can be
effortlessly manoeuvred with the built-in AMAL animation language, so
you don't have to be a machine code wizard in order to create your own
stunning arcade games.

  Hardware sprites are searate images which can be automatically
overlayed on the Amiga's screen. The classic example of a hardware
sprite is the mouse pointer. This is completely independent of the
screen, and works equally well in all the Amiga's graphics modes.

  Since sprites don't interfere with the screen background, they are
perfect for the moving objects required by an arcade game. Not only are
they blindingly fast, but they also take up very little memory. So when
you're writing an arcade game, hardware sprites should always be at the
top of your list.

  Each sprite is 16 pixews wise and up to 255 pixels high. The Amiga's
hardware supports a maximum of eight three-colour sprites or four
fifteen-colour sprites. Colour number zero is transparent - that's the
reason for the odd colour ranges.

  At first glance, these features don't seem particulary impressive.
But there are a couple of useful tricks which can increase both the
numbers and sizes of these sprites beyond recognition.

  One solution is to take each hardware sprite and split it into a
number of horizontal segments. These segments can be independently
positioned, allowing you to apparently display dozens of sprites on the
screen at once. Similarly, the width restriction can be exceeded by
building an object out of several individual sprites. Using this
technique it's easy to generate objects up to 128 pixels wide.

  Until recently the only way to exploit these techniques was to delve
into the mysterious wolrd of 68000 assembler language. So you'll be
delighted to discover that AMOS Basic manages the entire process
automatically! Once you've designed your sprites with the AMOS sprite
editor, you can effortlessly manipulate them with just a single Basic
instruction.


The sprite commands
===================
Remember to have a sprite bank loaded into memory when trying out the
various commands in this chapter. We advise you use the file
SPRITES.ABK from the AMOS data disc.



           SPRITE (display a hardware sprite on the screen)

SPRITE n,x,y,i

The SPRITE command displays a hardware sprite on the screen at
coordinates x,y using image number i.

  n is the identification number of the sprite and can range from 0 to
63. Each sprite can be associated with a separate image from the sprite
bank, so the same image can be used for several sprites.

  x and y hold the position of the sprite using special hardware           146
coordinates. All measurements are taken from the *hot spot* of your
images. This serves as a sort of 'handle' on the sprite and is used as
a reference point for the coordinates. Normally the hot spot is set to
the top left hand corner of an image. However it can be changed within
your program using the HOT SPOT command.

  Hardware coordinates are independent of the screen mode and
effectively start from (-129,-45) on the default screen. AMOS provides
you with several built-in functions for conversions between hardware
coordinates and the easier to use screen coordinates. See the X HARD,
Y HARD, X SCREEN and Y SCREEN functions for more details.

  i is the number of a particular image stored in the sprite bank. This
bank can be created using the AMOS sprite editor, and is automatically
saved along with your Basic program. It can also be loaded directly
with the LOAD instruction. In addition you can use the GET SPRITE
command to grab an image straight off the current screen.

  Any of these parameters x,y and i may be optionally omitted, but the
appropriate commas must be included. For example:

        Load "AMOS_DATA:Sprites/Octopus.abk"
        Sprite 8,200,100,1
        Sprite 8,,150,1
        Sprite 8,300,,

For a demonstration of sprites in action, load EXAMPLE 11.1 from the
MANUAL folder on the AMOS data disc.


Computed sprites
================
Although the Amiga only provides you with eight actual sprites, it's
possible to use them to display up to 64 different objects on the
screen at once. These objects are known as -computed sprites- and are
managed antirely by AMOS Basic. Computed sprites can be assigned by
calling the SPRITE command with a number greater than 7. For example,

        Load "AMOS_DATA:Sprites/Octopus.abk"
        Sprite 8,200,100,1

The size of a computed sprite is taken directly from the image data,
and can vary between 16 and 128 pixels wide, and from 1 to 255 pixels
high.

  Before you can make full use of these sprites you need to understand
some of the principles behind them. Each hardware sprite consists of a
thin narrow strip 16 pixels wide and 256 pixels deep. Depending on the
number of colours, you can have either eight or four of these strips on
the screen at a time.

  It should be obvious that most of the area inside these sprites is       147
effectively wasted. That's because few programs need sprites which are
taller than about 40 or 64 pixels. However there is a simple trick
which enables us to borrow this space to generate dozens of extra
objects on the screen. Look at the picture AMOS1.PIC (included in this
manual file packet) which contains the letters A,M,O and S.

           < picture   AMOS1.PIC >

This sprite can be split into four horizontal segments each enclosing a
single letter. The Amiga's hardware allows each section to be freely
positioned anywhere on the current line, making a total of four
computed sprites. Here's a diagram which illustrates this process.

           < picture   AMOS2.PIC >                                         148

As you can see, a computed sprite is really just a small part of a
hardware sprite displayed at a different horizontal screen position.
Notice the line between each object. This is an unavoidable side effect
of the repositioning process, and is generated by the Amiga's hardware.

  Due to the way computed sprites are produced, there are a couple of
restrictions to their use. Firstly, you can't have more than 8 computed
sprites on a single line. In practice the system is complicated by the
need to produce sprites which are larger than the 16 pixel maximum.
AMOS generates these objects by automatically positioning several
computed sprites side by side. This can be seen from the diagram below:

           < picture   AMOS3.PIC >

The maximum of eight hardware sprites therefore imposes a strict limit
to the number of such objects you can display on a horizontal line. The
total width of the objects must not exceed:

        16*8=128 pixels for three-colour sprites                           149
        16*4=64  pixels for fifteen-colour sprites

If you attempt to ignore limitation, you won't get an error message,
but your computer sprite will not be displayed on the screen. So it's
vital to ensure that the above restriction is never broken. This can be
achieved using the following procedure:

  Add together the widths of all your computed sprites, multiplying the
dimensios of any fifteen-colour sprites by two. If the total is
greater than 128, you'll need to space your sprites on the screen so
that their combined width lies below this value. Take particular care
if you are animating your sprites with AMAL as certain combinations
will only come to light after you've experimented with the sequence for
some time. These problems will be manifested by the random
disappearance of one or more sprites on the screen.

  If the worst comes to the worst, you'll need to substitute some of
your larger sprites with Blitter Objects. This will increase the
overall size of your program significantly, but it should have a
negligible effect on the final quality of your game.

  These restrictions are not confined to AMOS Basic of course. They
apply equally well to all games on the Amiga, even if they're written
entirely in machine code! So there's nothing stopping you from
producing your own Xenon II clone using exactly the same tehcniques.

  Note that, normally, hardware sprite number zero is allocated to the
mouse cursor. You can release this sprite with a simple call to the
HIDE command. See EXAMPLE 11.2.


Creating an individual hardware sprite
======================================
The only real problem with computed sprites is that you never know
precisely which hardware sprite is going to be used in a particular
object. Normally the hardware sprites used in an object will change
whenever the object is moved. Occasionally this can be inconvenient,
especially when you are animating objects such as missiles which need
to remain visible in a wide range of possible sprite combinations.

  In these circumstances it's useful to be able to allocate a hardware
sprite directly. Individual hardware sprites can be assigned using the
SPRITE instruction with an identification number between 0 and 7.
Example:

        Sprite 1,100,100,2

This loads a hardware sprite number 1 with image number 2. N now
corresponds to the number of a single hardware sprite, and can range
between 0 and 7. If your image is larger than sixteen pixels wide, AMOS
will automatically grab the required sprites in consecutive order
starting from the sprite you have chosen. For example:

        Sprite 2,200,100,1

Supposing image number 1 contained a 32-bit image with three colours.
This command would allocate hardware spries 2 and 3 to the image.
Nothing would happen if you were now to attempt to display hardware
sprite 3 with a command like SPRITE 3,150,100,1  because this sprite
has already been used. You would only have access to sprites 0,1,4,5,6
and 7, and the maximum numbers and sizes of your computed sprites would
be reduced accordingly.

  Each 15-colour sprite is implemented using a pair of two three-colour    150
sprites. However, it's not possible to combinea ny two sprites in this
way. Only the combinations 0/1,2/3,4/5,6/7 are allowed. One side effect
of this, is that you should always assign your hardware sprites using
even sprite numbers. Otherwise, AMOS will start your sprite from the
next group of two, effectively wasting the first sprite.

  Also note that if you try to create a large fifteen-colour sprite
with this system, you could easily use up all the available sprites in
a single object.

  WARNING! If you are writing a screen scrolling game, you may
encounter problems using sprites in conjunction with the SCREEN OFFSET
and SCREEN DISPLAY commands. These generate a DMA clash between the
sprite system and the screen bit-maps, and can occasionally lead to
unwanted screen effects.

  This problem is only relevant if you are using hardware sprites 6/7.
When the screen is shifted to the left with SCREEN OFFSET, the amount
of time for your sprite updates is reduced, as the screen DMA has
priority over the sprite system. Unfortunately, there isn't enough
processing time to draw sprites 6/7, and they will therefore be
corrupted on your display.

  To clear up this problem, create sprites 6/7 as individual hardware
sprites and position them off the screen using negative coordinates.
This will stop AMOS Basic from using them in your computed sprites.
Providing sprites 6/7 are never displayed on the screen during your
scrolling operations, all will be well.


The sprite palette
==================
The colours required by a hardware sprite are stored in the colour
registers 16 to 31. Providing your current screen mode doesn't make use
of these registers, the sprite colours will be completely separate from
your screen colours. Interestingly enough, this is also the case for
the 4096-colour Ham mode. So there's nothing stopping you from
producing some mind-blowing Ham games with this system!

  However you will encounter real problems when using 32 or 64 colour
screen in conjunction with three colour sprites. This is because the
colours used by these sprites are grouped together in the following
way:
           Hardware sprites  Colour registers
           ----------------  ----------------
                 0 / 1         17 / 18 / 19
                 2 / 3         21 / 22 / 23
                 4 / 5         25 / 26 / 27
                 6 / 7         29 / 30 / 31

   Colour registers 16,20,24 and 28 are treated as transparent.

The difficulty arises due to the way AMOS generates computed sprites.
The hardware sprites used to produce these objects vary during the
course of a game, so it's vital to ensure that the three colours used
by each individual sprite are set to exactly the same values, otherwise
the colours of your computed sprites will change unpredictably. Here's
a small AMOS procedure which will perform the entire process for you       151
automatically.

        Procedure INIT_SPRITES
          Get Sprite Palette
          For S=0 To 3
            For C=0 To 2
              Colour S*4+C+17,Colour(C)
            Next C
          Next S
        Endproc

The above restriction does not, of course, apply to fifteen-colour
sprites. If you want to make the most of the Extra Half Bright or
32-colour modes, you may find it easier to avoid using four-colour
sprites altogether.



                    GET SPRITE PALETTE (grab sprite
                         colours into screen)

GET SPRITE PALETTE [mask]

This loads the entire colour palette used for your sprite images into
the current screen. The optional "mask" allows you to load just a
selection of the colours from the sprite palette. Each of the 32
colours is represented by a single bit in the mask, numbered from right
to left. The rightmost bit represents the status of colour zero, the
next vit colour 1, and so on. To load a colour simply set the
appropriate bit to 1. If, for instance, you wanted to copy just the
first four colours, you would set the bit pattern to:

        Get Sprite Palette %0000000000001111

Identically, since bobs use the same sprite bank as sprites, this
command can also be used to load the colours of a bob.


Controlling sprites
===================


                 SET SPRITE BUFFER (set height of the
                           hardware sprites)

SET SPRITE BUFFER n

This sets the work area in which AMOS creates the images of the
hardware sprits. Acceptable values for n range from 16 to 256. TO set
the correct value for n, simply examine the sprites in the sprite
editor and work out which is the largest sprite length wise. ANy sprite
that is larger than "n" will simply be truncated at the appropriate cut
off point.

  SET SPRITE BUFFER is supplied for your use so that you can claim back
any redundant memory our game or application simply doesn't use.

  The amount of memory consumed by the sprite buffer can be calculated
using the formula:

        Memory = N*4*8*3 = N*96

  So the minimum buffer size is 1536 bytes and the maximum is 24k.
Note: This command erases all current sprite assignments and resets the
mouse cursor to its original state.



                    SPRITE OFF (remove one or more                         152
                       sprites from the screen)
SPRITE OFF [n]

The SPRITE OFF command removes one or more sprites from the screen. All
current sprite movements are aborted. In order to restart them, you'll
need to completely reinitialize your movement pattern.

SPRITE OFF    Removes all the sprites from display

SPRITE OFF n  Only deactivates sprite number n

Note that your sprites are automatically deactivated whenever you call
up the AMOS Basic editor. They will be automatically returned to their
original positions the next time you enter direct mode.



               SPRITE UPDATE (control sprite movements)

SPRITE UPDATE [ON/OFF]

The SPRITE UPDATE command provides you with total control of the
movements of your sprites. Normally, whenever you move a sprite, its
position is updated automatically during the next vertical blank period
(see WAIT VBL). But if you are moving a lot of sprites using the SPRITE
command, the updates will occur before all the sprites have been moved.
This may result in a noticeable jump in yur movement patterns. In these
circumstances, you can turn off the automatic updating system with the
SPRITE UPDATE OFF command.

  Once your sprites have been succesfully moved, you can then slide
them smoothly into place with a call to SPRITE UPDATE. This will
reposition any sprites which have moved since your last update.



               =X SPRITE (get x coordinate of a sprite)

x=X SPRITE(n)

Returns the current x coordinate of sprite n, measured the hardware
system. This command allows you to quickly check whether a sprite has
passed of the edge of the Amiga's screen.



               =Y SPRITE (get y coordinate of a sprite)                    153

y=Y SPRITE(n)

Y SPRITE returns a sprite's vertical position. As usual, n refers to
the number of the sprite and can range from 0 to 63. Remember, all
sprite positions are measured in hardware coordinates. See EXAMPLE 11.3



               GET SPRITE (load a section of the screen
                         into the sprite bank)

GET SPRITE [s,] i,x1,y1 TO x2,y2

This instruction enables you to grab images directly off the screen and
turn them into sprites. The coordinates x1,y1 and x2,y2 define a
rectangular area to be captured into the sprite bank. Normally all
images are taken from the current screen. However it's also possible to
grab the image from a specific screen using the optional screen number
"s".

  Note: There are no limitations to the region that may be grabbed in
this way. Providing your coordinates lie inside the existing screen
borders, everything will be fine.

  i denotes the number of the new image. If there is no existing sprite
with this number, a new image will be created automatically. AMOS wlil
also take the trouble of reserving the sprite bank if it hasn't been
previously defined. See EXAMPLE 11.4

  There's also an equivalent GET BOB instruction which is identical to
GET SPRITE in every respect. Since the sprite bank is shared by both
bobs and sprites, the images are in exactly the same format. So it's
perfectly acceptable to use both instructions in conjunction with
either bobs or sprites. Try changing the sprite instruction in the
previous example to something like:

        Bob 1,0,0,1


Conversion functions
====================


                 =X SCREEN (convert hardware coordinates
                 =Y SCREEN  into screen coordinates)

x=X SCREEN([n,] xcoord)
y=Y SCREEN([n,] ycoord)

Transforms a hardware coordinate into a screen cordinate relative to
the current screen. If the hardware coordinates lie outside the screen
then both functions will return relative offsets from the screens
boundaries. Type the following from direct mode:

        Print X Screen(130)

The result will be -2. This is because the x screen coordinate 0 is
equal to hardware coordinate 128 and thus the conversion of 130 to a
screen coordinate results in a position two pixels to the left of the
screen.

  If the optional screen number is included then the coordinates will
be returned relative to screen # n.



                  =X HARD (convert screen coordinates                      154
                  =Y HARD  into hardware coordinates)

X=X HARD ([n,] xcoord)

These functions convert a screen coordinate into a hardware coordinate.
There are four separate conversion functions, the above syntaz converts
xcoord from a coordinate relative to the current screen to a hardware
coordinate.

Y=Y HARD ([n,] ycoord)

Transforms a Y coordinate relative to the current screen into hardware
coordinate. As before, n specififes a screen number for use with the
functions. All coordinates will now be returned relative to this
screen.



             =I SPRITE (return current image of a sprite)

Image=I SPRITE(n)

This function returns the current image number being used by sprite n.
A value of zero will be reported if the sprite is not displayed.








                      12: BLITTER OBJECTS (BOBS)                           155
                     ----------------------------
While hardware sprites are certainly powerful, they do suffer from a
couple of annoying restrictions. The solution is to make use of the
Amiga's infamous Blitter chip. This is capable of copying images to
the screen at rates approaching a million pixels per second! With the
help of the blitter it's possible to create what are known as bobs.

  Bobs, like sprites, can be moved around completely independently of
the screen without destorying any existing graphics. But unlike
sprites, bobs are sroted as part of the current screen, so you can
create them in any graphics mode you wish. This allows you to generate
bobs with up to 64 colours. Furthermore the only limit to the number
of bobs you can display is dictated by the available memory.

  Bobs are slightly slower than sprites and they consume considerably
more memory. Therefore there's a trade-off between the speed of sprites,
and the flexibility of bobs. Fortunately there's nothing stopping you
from using both bobs and sprites in the same program.



                BOB (draw a bob on the current screen)

BOB n,x,y,i

The BOB command creates bob n at coordinates x,y using the image # i.

  n is the identification number of the bob. Permissible values
normally range from 0 to 63, but the number of bobs may be increased
using an option from the AMOS configuration program. Providing you've
enough memory, you can set this limit to any number you wish.

  x and y specify the position of the bob using standard screen
coordinates. These coordinates are not the same as the hardware
coordinates used by the equivalent SPRITE command. Like sprites, each
bob is controlled through a *hot spot*. This may be changed at any time
with the HOT SPOT command.

  i refers to an image which is to be assigned to the bob from the
sprite bank. The format of this image is identical to that used by the
sprites, so you can use the same images for either sprites or bobs.

  After you've created a bob, you can independently change either its
position or its appearance by omitting one or more parameters from this
instruction. Any of the numbers x,y or "image" may be left out, with
the missing parameters retaining their original values. This is
particularly useful if you are animating your bob with AMAL, as it
allows you to move your object anywhere you like, without disturbing
your existing animation sequence. However you must always include the
commas in their original order. Example:

        Load "AMOS_DATA:Sprites/Octopus.abk"
        Flash Off : Get Sprite Palette
        Channel 1 To Bob 1
        Bob 1,0,100,1
        Amal 1,"Anim 0,(1,4)(2,4)(3,4)(4,4)"                               156
        Amal On
        For X=1 To 320
          Bob 1,X,,
          Wait Vbl
        Next x

Whenever a bob is moved, the area underneath is replaced in its
original position, producing an identical effect to the equivalent
SPRITE command. Unlike STOS on the ST, each object is allocated its own
individual storage area. This reduces the amount of memory used by
bobs, and improves the overall performance dramatically. Due to the
Blitter, of course, therse's no real comparison between STOS sprites
and AMOS bobs.

  Although the BOB command works fine for small number of bobs, there's
an annoying flicker when you try to use more than three or four objects
on the screen at once. This happens because the bobs are updated at the
same time as the screen. You can therefore see the bobs while they are
being drawn which results in an unpleasant shimmering effect.

  One alternative for improving the quality of your animations is to
just limit your bobs to the bottom quarter of the screen. Since bobs
are redrawn extremely quickly, the updates can often be completed
before the lower part of the screen has been displayed. This provides
you with acceptably smooth movements while consuming very little
memory, so it's a useful trick if you're running short of space. See
EXAMPLE 12.1

  Obviously this cannot be seen as a serious solution to such a glaring
problem. So before you throw away your copy of AMOS Basic in disgust,
you'll be relieved to hear that there's a simple way of eliminating
this flicker completely, even when you're using dozens of bobs anywhere
on the screen:



             DOUBLE BUFFER (create a double screen buffer)

DOUBLE BUFFER

Creates a second invisible copy of the current screen. All graphics
operations, including bob movements, are now performed directly in this
*logical screen*, without disturbing your TV picture in the slightest.
Once the image has been redrawn, the logical screen is displayed, and
the original *physical* screen becomes the new logical screen. The
entire process now cycles continuously, producing a rock solid display
even when you're moving hundreds of bobs around the screen at once.

  The entire procedure is performed automatically by AMOS Basic, so
after you've executed this instruction you can forget about it
completely. Note that since the hardware sprites are always displayed
using the current physical screen, this system will have absolutely no
effect on any existing sprite animations.

  Double buffering works equally well in all of the AMIGA's graphics
modes. It can even be used in conjuction with dual playfields. But be
warned: Double buffering doubles the amount of memory used by your
screens. If you attempt to double buffer too many screens, you'll
quickly run out of memory. See EXAMPLE 12.2

  In practice, double buffering is an incredibly useful technique,
which can be readily exploited for most types of games. It has seen
service in the vast majority of commercial games, including Starglider
- that's why it's such an integral part of AMOS Basic. A detailed
explanation of this process can be found in the SCREENS chapter. ALso
see the SCREEN SWAP and AUTOBACK commands.



                   SET BOB (set drawing mode of bob)                       157

SET BOB n,back,planes,minterms

The SET BOB command changes the drawing mode used to display a bob on
the screen. n is the number of the bob you wish to affect.

  "back" chooses the way the background underneath your bob will be
redrawn. There are three possibilities:

 - A value of 0 indicates that the area underneath your bob should be
   saved in memory. The old image data is automatically replaced when
   the bob is moved, resulting a smooth movement effect.

 - if the "back" parameter is positive then the original background
   will be discarded altogether, and the area behind the bob will be
   filled with colour "back"-1. This is ideal for moving bobs over a
   solid block of colour such as a clear blue sky, as it's much faster
   than the standard drawing system.

 - Turn of the redrawing process completely by loading "back" with a
   negative value such as -1. You can now deactivate the automatic
   updating process using BOB UPDATE, and manually move your bobs with
   a call to BOB DRAW. This allows you to regenerate the screen
   background using your own customised drawing routines.

  "planes" is a bit map which tells AMOS which screen planes your bob
will be drawn in. As you may know, the Amiga's screen is divided up
into a number of separate bit-planes. Each plane sets a single bit in
the final colour which is displayed on the screen.

  The first plane is represnted by bit one, the second by bit two and
so on. Normally the bob is drawn in all the bit-planes in the current
screen mode. This corresponds to a bitpattern of %111111.

  By changing some of these bits to zero, you can omit selected colours
from your bobs when they are drawn. This can be used to generate a
number of intriguing screen effects.

  "minterms" selects the blitter mode used to draw your bobs on the
screen. A full description of the available modes can be found in the
section on SCREEN COPY. "minterm" is usually set to one of two values:

        %11100010   If the bob is used with a mask
        %11001010   if NO MASK has been set

Feel free to experiment with the various combinations. There's no
danger of crashing your Amiga if you make a mistake. Advanced Amiga
users find the following information useful.

        Blitter source  Purpose                                            158
        --------------  ------------------
              A         Blitter mask
              B         Blitter object
              C         Destination screen

Note that you are recommended to use SET BOB *before* displaying your
bobs on the screen. If you don't, the Amiga won't crahsh, and you won't
get an error message, but your screen display may be corrputed.



                     NO MASK (remove blitter mask)

NO MASK [n]

As a default, a blitter mask is automatically created for every bob you
display on the screen. This mask is combined with the screen background
to make colour zero transparent. It's also used by the various
collision detection commands.

  The NO MASK command removes this mask, and forces the entire image to
be drawn on the screen. Any parts of the image in colour zero will now
be displayed directly over the existing background.

  n is the image number whose mask is to be removed. This mask should
never be erased if the image is active on the screen, otherwise the
sasociated bob will be corrupted. If you must remove the mask in this
way, it's important to deactivate the relevant bobs with BOB OFF first.
Here's an example:

        Centre "Click mouse button to remove mask"
        Double buffer : Load "AMOS_DATA:Sprites/Octopus.abk"
        Get Sprite Palette
        Do
          Bob 1,X Screen(X Mouse),Y Screen(Y Mouse),1
          If Mouse Click Then Bob Off : No Mask 1
        Loop

See MAKE MASK


                        AUTOBACK (set automatic
                         screen copying mode)

AUTOBACK n

When you are using a double bufferend screen, it's essential to
synchronize your drawing operations with the movements of your blitter
objects. Remember that each double buffered screen consists of two
separate displays. There's one screen for the current picture, and
another for the image whilst it's being constructed. If the background
underneath a bob changes while it's being redrawn, the contents of
these screens will be different, and you'll get an intense and annoying
flickering efect.

  The unique AMOS AUTOBACK system provides you with a perfect solution
to this problem. It allows you to generate your graphics in any one of
three graphics modes, depending on the precise requirements of your
program. Just for a change, we'll list tese options in reverse order.


AUTOBACK 2 (automatic mode - default)                                      159

  In this mode, all drawing operations are automatically combined with
  the bob updates. So anything you draw on the screen will be displayed
  directly underneath your bobs, as if by magic. The principles behing
  this system can be demonstrated by the following code:

        Bob Clear : Rem    Draw on first screen ... Remove Bobs
        Plot 150,100 : Rem This can be anything you wish
        Bob Draw : Rem     Redraw bobs
        Screen Swap : Rem  Next Screen
        Wait Vbl
        Bob Clear
        Plot 150,100 : Rem Perform your operation a second time
        Bob Draw
        Screen Swap : Rem  Get back to first screen
        Wait Vbl

  As you can see, all screen updates are performed exactly twice.
  There's one operation for both the logical and the physical screen.
  See EXAMPLE 12.3 for a demonstration.

    One obvious side effect, is that your graphics now take twice as
  long to be drawn. Furthermore, the program will be halted by at least
  2 vertical blanks, every time you output something to the screen.
  This may cause annoying delays in the execution of critical
  activities such as collision detection.


AUTOBACK 1 (half-automatic mode)

  Performs each graphical operation in both the physical and logical
  screens. Absolutely no account is taken of your bobs, so you should
  only use this system for drawing outside the current playing area.

    Unlike the standard mode, there's no need to halt your program
  until the next vertical blank. Mode 1 is therefore ideal for objects
  such as control panels or hi-score tables, which need to be updated
  continually during the game.


AUTOBACK 0 (manual mode)

  Stops the AUTOBACK system in it's tracks. All graphics are now output
  straight to the logical screen at the maximum possible speed. You
  should use this option if you need to repeatedly redraw large
  sections of your background screen during the course of a game.
  This will allow you to safely perform your collision detection
  routines at regural intervals, without destroying the overall quality
  of the animation effects. Here's a typical program loop for you to
  examine.

        Bob Update Off
        Repeat
        Screen Swap
        Wait Vbl
        Bob Clear
        Rem Now redraw any of your gfxs which have changed                 160
        Rem Perform your game routines (Collision detection etc...)
        Bob draw
        Until WIN

Note that this procedure will ONLY work if there's a smooth progression
from screen to screen. It's entirely up to you to keep the contents of
physical and logical screen in step with each other. An example of this
technique can be found in EXAMPLE 12.4

  Supposing for instance, you wanted to display a bob over a series of
random blocks. You might try to use a routine like:

        Load "AMOS_DATA:Sprites/Sprites.abk" : Flash Off
        Get Sprite Palette : Double Buffer : Cls 0 : Autoback 0
        Update Off : Bob 1,160,100,1
        Do
          Bob Clear
          X=Rnd(320)+1 : Y=Rnd(200)+1 : W=Rnd(80)+1
          H=Rnd(50)+1 : I=Rnd(15)
          Ink I : Bar X,Y To X+W,Y+H
          Rem <this would normally call your collision detection routine>
          Bob Draw
          Screen swap : Wait Vbl
        Loop

But since there's no relationship between the physical and logical
screens, the display will now flick continuously from screen to screen.
To overcome this problem, you'll need to mimic the original AUTOBACK
system. Replace the lines in the previous example between the lines
Do and Loop  as follows:

          Rem Update first screen
          Screen Swap : Wait Vbl
          Bob Clear
          X=Rnd(320)+1 : Y=Rnd(200)+1 : W=Rnd(80)+1
          H=Rnd(50)+1 : I=Rnd(15)
          Ink I : Bar X,Y To X+W,Y+H
          Bob Draw
          Rem Update second screen
          Screen Swap : Wait Vbl
          Bob Clear
          Ink I : Bar X,Y To X+W,Y+H
          Bob Draw

The two screens are now updated with exactly the same information, and     161
the display remains as steady as a rock, even though there's a great
deal of activity going on in the background.

  Autoback can be safely used at any point in your program. So it's
perfectly possible to use separate drawing methods for the different
parts of your screen. It's also totally compatible with all graphics
operations including Blocks, Icons, and Windowing.


Bob Control commands
====================


                   BOB UPDATE (control bob movements

BOB UPDATE [ON/OFF]

Normally all bobs are updated once every 50th of a second using a
built-int interrupt routine. Alhouth this is convenient for most
programs, there are some applications which require much finer control
over the redrawing process.

  BOB UPDATE OFF turns off the bob updates and deactivates all
automatic screen switching operations if they've been selected. You may
now redraw your bobs at the most appropriate point in your program
using the BOB UPDATE command. This is ideal when you are animating a
large number of objects as it enables you to move your bobs into
position before drawing them on the screen. Inevitably this results in
far smoother movements in your game.

  One word of warning: The bob updates will only occur at the NEXT
vertical blank. Also note that BOB UPDATE will always redraw the bobs
on the current logical screen, so if you forget to use the SCREEN SWAP
command, nothing will apparently happen.



            BOB CLEAR (remove all the bobs from the screen)

BOB CLEAR

Removes all active bobs from the screen, and redraws the background
regions underneath. It's inteded for use with BOB DRAW to provide an
alternative to the standard BOB UPDATE command



                        BOB DRAW (redraw bobs)

BOB DRAW

Whenever the bobs are redrawn on the screen, the following steps are
automatically performed:

 1. All active bobs are removed from the LOGICAL screen and the
    background regions are replaced. This step is performed by BOB
    CLEAR.
 2. A list is made of all bobs which have moved since the previous
    update.
 3. The background regions under the new screen coordinates are saved
    in memory.
 4. All active bobs are redrawn at their new positions on the logical      162
    screen
 5. If the DOUBLE BUFFER feature has been activated, the physical
    and logical screens are now swapped

The BOB DRAW command performs steps 2 to 4 of this process directly.
Supposing you wished to create a screen scrolling arcade game. In this
situation, it would be absolutely vital for your scrolling operations
to be perfectly synchronized with movement effects. If the aliens were
to move while the scrolling was taking place, their background areas
would be redrawn at the wrong place. This would totally corrupt your
display, and would result in a hopeless jumble on the screen. Load
EXAMPLE 12.5 for a demonstration of this process.



                   =X BOB (get X coordinate of bob)

x1=X BOB(n)

Returns the current X coordinate of bob number n. This coordinate is
measured relative to the current screen. See also Y SPRITE, X MOUSE and
Y MOUSE.



                   =Y BOB (get Y coordinate of bob)

y1=Y BOB(n)

Y BOB complements the X BOB command by returning the Y coordinate of
bob number n. This value will be returned using normal screen
coordinates.



                 =I BOB (return current image of bob)

Image=U BOB(n)

This function returns the current image number being used by bob n. A
value of zero will be reported if the bob isn't displayed.



                LIMIT BOB (limit a bob to a rectangular
                         region of the screen)

LIMIT BOB [n,] x1,y1 TO x2,y2

This command restricts the visibility of your bobs to a rectangular
screen area enclosed by the coordinates x1,y1 to x2,y2. The x
coordinates are rounded up to the nearest 16-pixel boundary. Note that
the width of this region must always be greater than the width of your
bobs, otherwise you'll get an "illegal function call" error.

  If it's included, n specifies the number of a single bob which is to
be affected by this instruction, otherwise *all* bobs will be
restricted. You can restore the visibility limit to the entire entire
screen by typing:

        LIMIT BOB



                 GET BOB (load a section of the screen                     163
                         into the sprite bank)

GET BOB [s,] i,x1,y1 TO x2,y2

This instruction is identical to the GET SPRITE command. It grabs an
image into the sprite bank from the current screen.

  x1,y1 to x2,y2 are the coordinates of the top and bottom corners of
the rectangular area to be grabbed.

  i specifies the image number which is to be loaded with this area. s
selects an optional screen number from which the image is to be taken.
See GET SPRITE for more details. See also EXAMPLE 12.6.



             PUT BOB (fix a xopy of a bob onto the screen)

PUT BOB n

This is the exact opposite of the previous GET BOB command. The action
of PUT BOB is to place a copy of bob number n at its present position
on the screen. It works by preventing the background underneath the bob
from being redrawn during the next vertical blank period. In order to
synchronise the bob updates with the screen display, you should always
follow this command with a WAIT VBL instruction.

  Note that after this instruction has been performed, the original bob
may be moved or animated with no ill efects.



               PASTE BOB (draw an image from the sprite
                          bank on the screen)

PASTE BOB x,y,i

The PASTE BOB command draws a copy of image number i at *screen*
coordinates x,y. Unlike PUT BOB this image is drawn on the screen
immediately, and all the normal clipping rules are obeyed. See PASTE
ICON.


                BOB OFF (remove a bob from the display)

BOB OFF [n]

Occasinoally, you may wish to remove certain bobs from the screen
altogether. The BOB OFF command erases bob number n from the screen and
terminates any associated animations. If n is omitted, all bobs will be    164
removed by this instruction.





                          13: OBJECT CONTROL                               165
                      ---------------------------
In this section you will find out how the various objects generated
using the sprite and bob commands can be controlled from within an AMOS
Basic program. The topics under discussion include collision detection,
using the mouse cursor and reading the joystick.


The mouse pointer
=================
The mouse cursor provides the games programmer with a valuable
alternative to the standard joystick. With the CHANGE MOUSE command you
can replace the mouse with an image in the current sprite bank. There's
also a group of instructions which allow you to determine both the
position and status of this mouse at any time. These include the
X MOUSE, Y MOUSE and MOUSE KEY instructions.



              HIDE (remove mouse pointer from the screen)

HIDE [ON]

This command removes the mouse pointer from the screen completely. A
count of the number of occasions you have called this function is kept
internally by the system. This needs to be matched by an equal number
of SHOW instructions before the pointer will be returned on the screen.

  There's also another version of this instruction which can be
accessed with HIDE ON. This ignores the count and *always* hides the
mouse, no matter how many times you've called the SHOW command.

  Note that HIDE only makes the mouse pointer invisible. It has no
effect on any other AMOS commands, so you can still use X MOUSE and
Y MOUSE functions to read the coordinates of the mouse as normal.



                   SHOW (activate the mouse pointer)

SHOW [ON]

This returns the mouse pointer to the screen after a HIDE instruction.
Works the same way that HIDE does.



                   CHANGE MOUSE (change the shape of
                          the mouse pointer)

CHANGE MOUSE m

This allows you to change the shape of the mouse at any time. Three
mouse patterns are provided as standard. These can be assigned using
the numbers 1-3.

If you specify a value m greater than 3, this is assumed to refer to an    166
image stored in the sprite bank. The number of this image is determined
using the expression I=m-3. So image number 1 would be installed by a
value of 4.

  In order to use this option, your sprite image must be exactly 16
pixels wide and have no more than four colours. However there's no such
limit to the height of your image.



               =MOUSE KEY (read status of mouse buttons)

k=MOUSE KEY

Enables you to quickly check whether one or more of the mouse keys have
been pressed. It returns a bit-pattern which holds the current status
of the mouse buttons.

        Bit 0   Set to 1 if the LEFT   button pressed, otherwise zero.
        Bit 1   Set to 1 if the RIGHT  button pressed, otherwise zero.
        Bit 2   Set to 1 if the MIDDLE button pressed (if available).



                =MOUSE CLICK (check for a mouse click)

c=MOUSE CLICK

Checks wheter the user has "clicked" on a mouse button. Uses the same
bit pattern indication as =MOUSE KEY.

One shot tests are only set to 1 when the mouse key has just been
pressed. These bits are automatically reset to zero after they've been
tested once. So they will only check for a single key press at a time.



       =XMOUSE= (get/set the X coordinate of the mouse pointer)            167

x1=X MOUSE

X MOUSE returns the current X coordinate of the mouse pointer in
hardware notation. You can also use this function to move the mouse on
to a specific screen position. This can be achieved by assigning X
MOUSE with a value, just like a Basic variable, for example:

        X MOUSE=150



       =YMOUSE= (get/set the Y coordinate of the mouse pointer)

y1=Y MOUSE

Returns the Y coordinate of the mouse pointer. This can also be used to
set the Y position of the mouse pointer the same way as using X MOUSE.
See EXAMPLE 13.1 for an example of the X MOUSE and Y MOUSE.



                 LIMIT MOUSE (limit mouse to a section
                            of the screen)

LIMIT MOUSE x1,y1 TO x2,y2

Restricts mouse movements to the rectangular area defined by the
hardware coordinates (x1,y1) and (x2,y2). Note that unlike LIMIT BOB,
the mouse is completely trapped inside this zone and cannot be moved
beyond it. Simply use this instruction with no parameters to restore
the mouse to the full screen area.

        LIMIT MOUSE

See also EXAMPLE 13.2 from the manual folder for a demonstration.


Reading the joystick
====================
AMOS Basic includes six functions which allow you to immediately check
the movements of a joystick insterted in either of the available
sockets.



                         =JOY (read joystick)                              168

d=JOY(j)

This function returns a binary number which represnts the current
status of a joystick in port number j. Normally your joystick will be
placed in the left socket (number 1). However you can remove the mouse
from the right-hand socket and replace it with a joystick. This can be
accessed using port # 0.

  The state of the joystick can be read by inspecting the pattern of
binary bits in the result. Each bit indicates whether a specific action
has been performed by the user. If a bit is set to one then the test
has proved positive and the joystick has been moved in the appropriate
direction. Here's a list of the various bits and their meanings:

        Bit Number   Significance
        ----------   ------------
            0        Joy moved up
            1            "     down
            2            "     left
            3            "     right
            4        Fire button pressed

See EXAMPLE 13.3

You can also use the following commands, if you are not familiar with
this binary notation:



                =JLEFT(j) (test joystick movement left)
               =JRIGHT(j) (test joystick movement right)
                  =JUP(j) (test joystick movement up)
                =JDOWN(j) (test joystick movement down)                    169

x=JLEFT(j)
x=JRIGHT(j)    These functions return a value of -1(true) if the
x=JUP(j)       joystick in port j has been pulled to the associated
x=JDOWN(j)     direction. Value 0 is reported, if the condition is
               false (joystick hasn't been moved to the asked
               direction).


Detecting collisions
====================
If you're writing an arcade game it's vital to be able to accurately
check for collisions between the various objects on the screen. AMOS
Basic includes five powerful functions which allow you to perform these
tests quickly and easily.


Detecting collisions with a sprite
----------------------------------


                 SPRITE COL (detect collisions between
                         two hardware sprites)

c=SPRITE COL (n [,s TO e])

This provides you with a simple way of testing to see whether two or
more sprites have collided on the screen. The number n refers to an
active hardware sprite which is to be clicked for a collision. If a
collision has occurred a value of -1(true) will be returned, otherwise
the result will be set to 0 (false).

  The standard from of this function checks for all collisions. But you
can also test a whole group of sprites using an extended version of the
command:

        c=SPRITE COL n,s TO e

The above instruction checks for collisions between sprite n and
sprites s to e (inclusive). Once you've detected a collision, you can
then get the individual sprite numbers which have vollided using the
COL function.

  NOTE that in order to use this function, you'll need to create a
sprite mask with the MASK command first, otherwise your collisions will
not be detected. A detailed example of this command can be found in
EXAMPLE 13.4.


Detecting collisions with a bob                                            170
-------------------------------


                  BOB COL (detect collisions between
                         two blitter objects)

c=BOB(n, [,s TO e])

The BOB COL function checks bob number n for a collision with another
bob. If a collision has been detected, the value returned in c will be
set to -1 (true), otherwise it will be 0.

  Normally the command will check for all collisions, but you can
specify a collection of bobs to be tested using the optional range
parameters s to e. The status of these bobs can be individually
examined with the COL command. See EXAMPLE 13.5.


Collisions between bobs and sprites
-----------------------------------


              SPRITEBOB COL (test for a collision between
                           sprites and bobs)

c=SPRITEBOB COL(n [,s TO e])

This function checks for a collision between SPRITE n ane one or more
BOBS. The value of c will be either -1 if a collision has been
discovered, or 0 if there have been no collisions. The starting and
ending points specify that collisions will only be detected between the
bobs s to e. If they are not included then all active bobs will be
tested by this instruction.

  WARNING! Collision detection between a sprite and a bob is only
possible on a low resolution screen. In HiRes mode, the pixel sizes
used for bobs and sprites are totally different, and the results from
this function will be unreliable.



              BOBSPRITE COL (test for a collision between
                           bobs and sprites)

c=BOBSPRITE COL(n, [,s TO e])

The BOB SPRITE COL function checks for collisions between a single bob
and several sprites. The results and usage of this instruction are
same as in the SPRITEBOB COL. See EXAMPLE 13.6.



                 =COL (test the status of a sprite or
              bob after a collision detection intruction)

c=COL(n)

The COL array holds the status of all the objects which have been
previously tested by the collision detection functions.

  Each object you have checked is associated with one element in this
array. This element will be loaded with -1 if a collision has been
detected with object number n, or 0 if it has not. The numbering system
is simple: The first element in the array holds the status of object
number 1, the second represents object number 2, and so on. See EXAMPLE
13.7.

  If you are using the SPRITE COL or BOBSPRITE COL instructions then
the objects will be hardware sprites, otherwise they will be bobs. In
order to avoid confusion, it's sensible to call this instructoin
immediatly after the relevant detection command.



                HOT SPOT (set the hot spot for an image                    171
                          in the sprite bank)

HOT SPOT image,x,y
HOT SPOT image,p

This command sets the hot spot of an image stored in the current sprite
bank. The hot spot of the object is used as a reference point for all
coordinate calculations. There are two versions of this instruction.

        HOT SPOT image,x,y

x and y coordinates measured from the top left corner of the image.
These coordinates will be added to the sprite bank or bob coordinate to
position an object precisely on the screen.

              Sprite image
              +----------+        Note that it's perfectly
              :          :        lefal for the hot spot
              : x        :        to lie outside the
              :<-->*     :        actual image.
              :  hot spot:
              +----------+

        HOT SPOT image,p

This is a short form of the instruction which moves the hot spot to one
of nine predefined positions. The positions are shown in the diagram
below where the centre point of the image is represent by a value of       172
$11.

        $00     $10     $20
        $01     $11     $21        See EXAMPLE 13.8.
        $02     $12     $22



                        MAKE MASK (make a mask
               around an image for collision detection)

MAKE MASK [n]

Defines a mask around image number n in the sprite bank. This is used
by all the AMOS Basic collision detection commands. You should
therefore create a mask for every object you wish to check. If you omit
the image number n, then a mask will be generated for each image in the
sprite bank. This may take a little time.

  It's important to note that masks are generated automatically when a
bob is first drawn on the screen. This might cause a significant delay
in the running of your program, so it's worthwhile placing an explicit
call to MAKE MASK during your initialisation procedure.


Collisions with rectangular blocks
----------------------------------
AMOS Basic includes a number of functions which allow you to quickly
check whether a sprite or bob has entered a rectangular region of the
screen.

  These screen zones are especially useful for collision detection in
rebound games such as Arkanoid as each block can be assignet its own
individual screen zone. You can also use zones to construct the buttons
and switches needed for control panels and dialogue boxes.



           RESERVE ZONE (reserve space for a detection zone)

RESERVE ZONE [n]

RESERVE ZONE allocates enough memory for exactly n detection zones.
This command should always be used before defining a zone with SET
ZONE.

  The only limit to the number of zones is the amount of available
memory, so it's perfectly feasible to define hundreds or even thousands
of zones in one of your programs. To erase the current zone definitions
and restore the memory back to the main program, simply type

        RESERVE ZONE    with no parameters.



                   SET ZONE (set a zone for testing)

SET ZONE z,x1,y1 TO x2,y2

Defines a rectangular zone which can be subsequently tested using the
various ZONE commands. z specifies the number of the zone to be created
and x1,y1 and x2,y2 input the coordinates of the top left and bottom
right hand corners of the rectangle.

  Before using this instruction you'll need to reserve some space for
your zones with RESERVE ZONE.



                   =ZONE (return the zone under the                        173
                   the requested screen coordinates)

t=ZONE([s],x,y)

ZONE returns the number of the screen zone at the graphic coordinates
x,y. Normally the coordinates are relative to the current screen - you
can also include an optional screen number s in this function.

  After ZONE has been called, t will hold either the number of the zone
at the specified coordinates or a value of 0 (false).

  Note that ZONE only returns the first zone at these coordinates - it
won't detect any other zones which lie inside this region.

  It is possible to use this function in conjunction with X BOB and
Y BOB functions to detect whether a bob has entered a specific screen
zone. This can be accomplished using the following code:

        X=Zone(X bob(n),Y Bob(n))

See Examples 13.9 and 13.10.



                   =HZONE (return the zone under the
                    requested hardware coordinates)

t=HZONE([s],x,y)

HZONE is almost identical to ZONE except that the screen position is
now measured in hardware coordinates. You can therefore use this
function to detect when a hardware sprite enters one of your screen
zones. For example:

        X=Hzone(X Sprite(n),Y Sprite(n))

See also EXAMPLE 13.11, and ZONE, MOUSE ZONE, SET ZONE and ZONE$



              =MOUSE ZONE (check wheter the mouse pointer
                          has entered a zone)

x=MOUSE ZONE

The MOUSE ZONE function returns the number of the screen zone currently
occupied by the mouse pointer. It's equibalent to the line:

        X=Hzone(X mouse,Y mouse)



                       RESET ZONE (erase a zone)                           174

RESET ZONE [z]

This command permanently deactivats any of the zones created by SET
ZONE. If the optional zone number z is included then only this zone
will be reset, otherwise all the zones will be affected. Note that
RESET ZONE only erases the zone definitions, it does not return the
memory allocated by RESERVE ZONE.


Bob priority
============


            PRIORITY ON/OFF (change between priority modes)

PRIORITY ON/OFF

Each bob is assigned a priority value ranging from 0-63. Amos basic
uses this number to decide which order the objects should be displayed
on the screen. As a rule, any bob with the highest priority will always
be displayed in front if any objects with a lower priority. The
priority value is taken directly from the number of a Bob.

  You should remember this fact when assigning numbers to your bobs.
The choise of number can have wide ranging effects on the appearance of
your objects on the screen.

  In addition to the standard system, it's also possible to arrange the
bobs according to their position on the screen. PRIORITY ON assigns the
greatest priority values to the bobs with the highest Y coordinates.
This allows you to create a useful illusion of perspective in your
games. Look at the example below:

        Load "AMOS_DATA/Sprites/Monkey_right.abk" : Cls : Flash Off
        Get Sprite Palette
        Priority Off : Rem Set normal mode
        Bob 1,160,100,2 : Bob 2,0,72,2 : Bob 3,320,128,2
        Channel 2 To Bob 2 : Channel 3 to Bob 3
        Amal 2," Loop: M 320,0,320 ; M -320,0,320 ; Jump Loop"
        Amal 3," Loop: M -320,0,320 ; M 320,0,320 ; Jump Loop"
        Amal On
        Wait Key
        Priority On : Rem Set Y mode
        Wait Key

Normally, both moving bobs pass below the object in the centre. When
you change the priority system with a call to PRIORITY ON, the bobs are
now ranked in order of their increasing Y coordinates. So bob three
moves aboce bob one while at the same time, bob two passes smoothly
behind it.

  HINT: It's usually best to position the Hot Spot of the sprite at its
base. This is because the Y coordinates used by this command relate to
the position of the Hot Spot on the screen. Also notice that the
PRIORITY OFF instruction can be utilised to reset the priority back to
normal.


Miscellaneous commands                                                     175
======================


             UPDATE (change automatic sprite/bob updates)

UPDATE [ON/OFF]

Normally any objects you draw on the screen will be automatically
redisplayed whenever they are animated or moved. This feature can be
temporarily halted using the UPDATE OFF command. When the updates are
not active the SPRITE, BOB and AMAL commands apparently have no effect.
Actually, all your animations are working correctly - it's just that
the results are not being displayed on the screen. You can force this
redrawing operation at any time using the UPDATE command. Here are the
three different forms of the UPDATE instruction.

        UPDATE OFF

Turns of the automatic updating.

        UPDATE

Redraws any sprites which have changed their original positions

        UPDATE ON

Returns the sprite updating to normal. See EXAMPLE 13.12.